The Secure Socket Layer (SSL) protocol is widely used to protect privacy and integrity of communications across networks. The SSL protocol creates a secure connection between a client and a server allowing data to be securely exchanged over the connection. The SSL protocol utilizes certificates to authenticate the remote server to the client, and optionally to authenticate the client to the server. The SSL protocol also utilizes symmetric key encryption and integrity protection to securely transfer data. Accordingly, the protocol enables identification of the remote side of the network conversation and prevents third parties from accessing the data being sent.
FIG. 1 shows an exemplary network 100 adaptable for communication using the SSL protocol. The exemplary network 100 includes a client device 110 communicatively coupled to a server device 115. The client device 110 may be a personal computer, a client computer, a hand-held or laptop device, a set top box, a programmable consumer electronic and/or the like. The server device 120 may be a personal computer, a host computer, a server computer, a hand-held or laptop device, a set top box, a mini-computer, a mainframe computer, a distributed computer system and/or the like.
The client device 110 and the server device 115 may be directly coupled to each other or indirectly coupled to each other through one or more networks 120, 125, 130. The networks 120, 125, 130 may include a plurality of communication channels 135, 140 and one or more other computing devices 145, 150. The networks 140 may include an intranet, an extranet, the Internet, a wide-area network (WAN), a local area network (LAN), and/or the like. The communication channels 130, 135 and networks 140 may implement any connectivity strategies, such as broadband connectivity, modem connectivity, digital subscriber link (DSL) connectivity, wireless connectivity or the like.
In one implementation, the client device 110 may be communicatively coupled to a client-side device 145 in a client-side network 120. The client-side device 145 may be a proxy server, firewall or other front-end type device. Although not shown, one or more additional client-side devices may also be communicatively coupled to the client-side device 145. The client-side network 120 may, for example, be a corporation's local area network. The server device 115 may be communicatively coupled by a server-side device 160 to one or more other networks 125, 120. The server-side device 150 may be a proxy server, firewall and/or other front-end type device. The server-side network 130 may also include one or more additional server-side devices (not shown).
The SSL protocol includes a handshake phase for establishing a socket connection and a session phase for securely sending data between the client and server devices 110, 115. Referring now to FIG. 2, a technique of establishing an SSL session in the exemplary network of FIG. 1 is shown. The handshake phase 200 includes exchanging commands to initiate the session, to determine the version of SSL implemented by the client device and the server device, to determine the cipher libraries supported by the devices, to determine the data compression methods supported by the devices, to specify a session identifier and to exchange random data for use in the generating session keys.
The handshake phase 200 further includes transmitting the certificate 210 of the server 115 to the client device 110. The client device 110 authenticates the identity that the certificate claims to represent. Among other things, authenticating the server 115 includes determining if the distinguished name of the issuer (Issuer's DN) specified in the server's certificate 210 corresponds to a certificate authority contained in a list of trusted certificate authorities 220 maintained on by the client device 110. It is also determined if the issuing certificate authority's public key validates the issuer's digital signature contained in the server's certificate 210. The client device 110 also verifies that the current date is within the validity period specified in the server's certificate 210. The client device 110 further determines that the DN specified in the server's certificate 210 matches the uniform resource locator that the client device is attempting to communicate with), when validating the identity of the server.
If the identity of the server device 115 is authenticated, the data generated in the handshake phase 200 so far is utilized by the client device 110 to generate a pre-master secret 230 for the session. The pre-master secret 230 is encrypted by the client device 110 utilizing the public key of the server that was contained in the authenticated server certificate 210. The client device 110 sends the encrypted pre-master secret 230, and if applicable the client's own certificate, to the server device 115.
The server device 115 uses its private key to decrypt the pre-master secret 230′. The client and server devices 110, 115 each generate a master secret 240, 240′ from the pre-master secret 230, 230′. Both the client and server 110, 115 use the master secret 240, 240′ to generate a session key 250, 250′. The session key 250, 250′ is a symmetric key that is used to encrypt and decrypt data exchanged during the session phase. The symmetric key enables rapid encryption, decryption and tamper detection, as compared to public-private key encryption techniques.
Referring now to FIG. 3, a technique of exchanging data during an SSL session 300 in the exemplary network of FIG. 1 is shown. During the session phase 300, messages 310 generated by the client device 110 are hashed 315 to generate a message digest 320. The message digest 320 is appended to the message 310 and the combination 325 is encrypted 330 utilizing the session key. The resulting encrypted packet 335 is then transmitted across one or more communication channels 340 and one or more networks to the server device. The server device 115 decrypts 345 the received packets 335′ utilizing the session key to recover the combined message 325′. The message portion of the combined message 325′ is hashed 350 to generate an authenticator 355. The authenticator 355 is compared 360 to the message digest portion of the combined message 325′. If the authenticator 355 and the message digest are equivalent, the server device 115 knows that the message has been received from the client device 110 and that it has not been altered during transmission. An equivalent process is also utilized to send messages from the server device 115 to the client device 110.
Accordingly, the handshake phase 200 of the SSL protocol uses digital certificates to authenticate the server device 115 to the client device 110, and optionally to authenticate the client device 110 to the server device 115. The handshake phase 200 utilizes public-private key encryption to transfer a secret from the client device 110 to the server device 115, if the identify of the devices 110, 115 are authenticated. The client and server devices 110, 115 may then generate the session key from the secret. The session key is utilized during the session phase 300 to securely exchange data between the client and server devices 110, 115.
The SSL protocol provides for end-to-end secure communication. More specifically, the encrypted packets transmitted between the client and server devices 110, 115 are tunneled through any intermediary devices 120, 150 of the networks 120, 125, 130. The encrypted messages are routed by intermediary devices 120, 150 according to a header that contains little more then routing information. The intermediary devices 120, 150 are unable to inspect the encrypted data. Accordingly, the SSL protocol makes it difficult to determine if a client device 110 is receiving malicious content, such as worms, viruses and the like, from the server device 115. The SSL encryption also makes it difficult to determine if a client device 110 is sending confidential data to the server 115. For example, in a proxied environment, the client-side proxy 145 tunnels the encrypted client traffic (e.g., data) to the server 115 without the ability to read and understand the data. Thus, the client-side proxy 145 is unable to apply an entity's security policy to data transferred utilizing the SSL protocol.